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DETAILED ACTION 
Notice to Applicant 

This communication is in response to the communication filed 07/31/2007. 
Pending claim(s): 1-7, 9-21, 23-35, 37-44. Cancelled claim(s): 8, 22, 36. New 
claim(s): 43-44. Amended claim(s): 1,15, 29. 

Examiner notes that the text of all pending claims submitted 06/04/2007 
does not indicate the correct status for claims 15, 29, i.e. (currently amended). 

Priority 

Acknowledgment is made of Applicant's claim for priority to applications 
60236726 filed 10/02/2000 and 60221558 filed 07/28/2000. 

Information Disclosure Statement 

The information disclosure statement (IDS) submitted on 07/31/2007 is 
entered and considered by Examiner. 



Drawings 

The drawings were received on 07/27/2001 . These drawings are 
acceptable. 
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Response to Amendment 

As per the rejection of claims 8, 22, 36 under 35 USC 112, second 
paragraph imposed in the previous Office Action, this rejection is hereby 
withdrawn in view of Applicant's cancellation of claims 8, 22, 36. 

As per the rejection of claims 2, 9-1 1 under 35 USC 102(b) as being 
anticipated by Evans (5924074), this rejection is hereby withdrawn in view of 
Applicant's arguments on page 10-11 of the Remarks filed 06/04/2007 (hereafter 
"Remarks"). 

Claim Objections 

Claim 14 is objected to because of the following informalities: "a 
messages". 

Claims 28, 42 are objected to because of the following informalities: 
"transmitting transmitted". 

Claim 41 is objected to because of the following informalities: claim 41 is 
recited as being dependent upon claim 39; however, claim 39 does not recite 
compressing, encrypting, or encapsulating. 

For purposes of applying prior art, Examiner interprets claim 41 to depend 
on claim 40. 
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Appropriate correction is requested. 

Claim Rejections - 35 USC §112 

The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

Claim(s) 1-7, 9-21, 23-35, 37-44 is/are rejected under 35 U.S.C. 112, 
second paragraph, as being indefinite for failing to particularly point out and 
distinctly claim the subject matter which applicant regards as the invention. 

As per claim 1, the limitation "image data in medical record modality 
formats and in multi-media formats" renders the scope of the claim indefinite. 
The terms "medical record modality formats" and "multi-media formats" are not 
defined by the claim, the specification does not provide a standard for 
ascertaining the requisite degree, and one of ordinary skill in the art would not be 
reasonably apprised of the scope of the invention. 

For purposes of applying prior art, Examiner interprets this limitation to 
recite a plurality of image formats. 

All claims dependent thereon, namely claims 2-7, 9-14 fail to remedy 
these deficiencies, and are therefore rejected for at least the same rationale as 
applied to claim 1 , and incorporated herein. 
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Claims 15-21, 23-35, 37-44 are also rejected for the same rationale as 
applied to claims 1-7, 9-14 above, and incorporated herein. 



Additional clarification is requested. 



Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for 
all obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described 
as set forth in section 102 of this title, if the differences between the subject matter sought to 
be patented and the prior art are such that the subject matter as a whole would have been 
obvious at the time the invention was made to a person having ordinary skill in the art to which 
said subject matter pertains. Patentability shall not be negatived by the manner in which the 
invention was made. 

The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 
148 USPQ 459 (1966), that are applied for establishing a background for 
determining obviousness under 35 U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at 
issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating 
obviousness or nonobviousness. 

Claim(s) 1-7, 9-11, 15-21, 23-25, 29-35, 37-39, 43-44 is/are rejected under 

35 U.S.C. 103(a) as being unpatentable over Evans in view of Hacker (6988075) 

and Applicant Admitted Prior Art (hereafter "AAPA"). 



As per claim 1, Evans teaches a system (It is noted that a system is 
considered to be "an apparatus") (Abstract), comprising: 
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(a) an EMR system (It is noted that the EMR system is considered to be "a 
computer system") (Abstract, column 2 line 21) capable of communicating with 
portable computers (It is noted that communicating with portable computers are 
considered to be "executing portability enabling software") (Abstract); 

(b) wherein the EMR system is capable of sharing patient medical records 
between a plurality of external systems (Figure 1 label 106, "EXTERNAL DATA", 
Figure 12, Figure 13 label 219, Figure 17A-B) via a data handler and a 
communication interface (Figure 16 label 272, 274, column 10 line 18-35), and a 
plurality of legacy systems via a data converter (column 12 line 35-53, Figure 
23); 

(c) wherein the EMR system is capable of supporting communication 
among a variety of hardware components (It is noted that a plurality of hardware 
components are considered to be "different... computer platforms") using a 
variety of operating systems (column 13 line 31-56), wherein the hardware 
components comprise: 

(i) a PC (Figure 24 label 412, 416, 418); 

(ii) a pen-based portable computer (It is noted that the pen-based 
portable computer is considered to be "a hand-held device") (Figure 24 
label 420); 

(iii) a network (Figure 24 label 404, 414); 

(d) wherein the EMR system is capable of populating and updating the 
patient record with text (Figure 14 label 223) and image data (Figure 14 label 
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225) from legacy data systems (column 8 line 57-60) and external sources 
(column 8 line 18 to column 9 line 37); 

(e) wherein image data is stored in a plurality of formats (Figure 14 label 

225); 

(f) wherein the EMR system is capable of capturing patient data during a 
patient encounter with a physician (It is noted that encounter data is considered 
to be "patient episode data") (column 6 line 10 line 10-36, Figure 4) and 
controlling access thereto via a password system (It is noted that the password 
system is considered to be "a secure file") (column 15 line 21-32); 

(g) wherein the patient data comprises e-mails from other healthcare 
providers (column 8 line 67 to column 9 line 1 ). 

Evans further teaches that the patient data repository comprises a 
relational database supporting the Open Database Connectivity (ODBC) model, 
wherein OBDC is an application program interface (API) capable of enabling 
client applications running under Microsoft Windows to access data from a 
variety of data sources, including relational and non-relational DBMS, wherein 
these data sources may reside on a client machine or on a remote server 
(column 14 line 8-25). 

Evans further teaches a patient locator capable of locating patient data in 
a plurality of external sources (column 8 line 18 to column 9 line 37). 

Examiner submits that the ODBC model and patient locator of Evans are 
considered to be a form of "a master control file" when viewed in light of 
Applicant's specification. 
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Notwithstanding the above, page 3 paragraph 3 of Applicant's 
specification reads as follows: 

"One way of providing a common set of medical information 
communications protocols, or common standards, is by an architecture which 
includes the use of a master control file. A master control file (or MCF) is 
middleware software storing information which, when read by a computer 
program referred to as an engine, provides an interface between an application 
program and the WINDOWS operating system. The master control file (or MCF) 
provides an open, interoperable, platform and language independent 
distributed (MCF) architecture . This approach has been enormously successful 
and has been adopted by numerous large firms around the world as the basic 
architecture for their complex Patient Record information systems. This 
infrastructure provides a great deal of power, scalability, and interoperability." 
(emphasis added) 

At the time the invention was made, it would have been obvious to one of 
ordinary skill in the art to include the features of AAPA within the invention as 
disclosed by Evans with the motivation of enabling client applications to access 
data from a plurality of external data sources (Evans; column 14 line 11-14). 

Evans and AAPA do not teach: 

(a) "transmitting the secure file as an e-mail attachment"; 

(b) "retrieving the patient episode data from the secure file"; 

(c) "storing the patient episode data in the medical records system". 
Hacker teaches a system (Abstract) capable of: 
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(a) attaching updated information from the patient visit to an e-mail 
(column 8 line 41-42); 

(b) translating the attached information by software on the server (It is 
noted that translating data is considered to be "retrieving") (column 8 line 43); 

(c) updating the patient medical record on the medical information 
database with the translated data (column 8 line 44-45). 

Evans teaches a password system, as discussed above and incorporated 

herein. 

It is also noted that the official notice taken in the previous Office Action is 
taken to be AAPA because Applicant failed to traverse Examiner's assertion. 
Page 7 of the previous Office Action reads as follows: "It is well known that 
emailing data over a network requires some form of security for the data". 

At the time the invention was made, it would have been obvious to one of 
ordinary skill in the art to include the features of Hacker and AAPA within the 
invention as disclosed by Evans and AAPA with the motivation of providing 
privacy for patient records (Hacker; column 6 line 1-10), and of providing 
convenience to medical providers who have their own electronic medical record 
system and only need access to very little "outside" medical information (Hacker; 
column 8 line 25-34). 

As per claim 2, Evans teaches a graphical user interface (It is noted that 
the GUI is considered to be "medical software") capable of being deployed on a 
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wireless pen-based or laptop computer (Figure 24, column 6 line 9-55, column 13 
line 12-30). 

As per claim 3, Evans teaches that the ODBC/API is capable of enabling 
client applications to access data from a variety of data sources, wherein the 
client is capable of storing, annotating, entering, and accessing patient medical 
records stored in the patient data repository (column 5 line 1-28, column 14 line 
8-25). 

As per claim 4, Evan teaches a data manager/patient locator capable of 
creating a data structure comprising a patient identifier, wherein the data 
structure comprises pointers to data structures having data within a patient 
record captured by a pointer of care system (e.g., X-ray images), wherein there 
exists a plurality of data structures created by the patient locator comprising 
patient data, interface files, clinical data, progress notes (Figure 13), wherein the 
files comprises patient data types (reads on "field names, attributes") (Figure 12 
column 8 line 29-60). 

As per claim 5, Evans teaches database tables comprising a plurality of 
field names, comprising a patient identifier (Figure 13), wherein the EMR system 
is capable of using the field names to locate, store, and retrieve data (Figure 13, 
column 5 line 1-28, column 8 line 29 to column 9 line 37). 
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As per claim 6, Evans teaches a plurality of pointers to a plurality of 
patient data structures, comprising a reference database, wherein the patient 
data structure and patient locator are capable of using the pointers to locate, 
store, and retrieve data (Figure 13, column 5 line 1-28, column 8 line 29 to 
column 9 line 37). 

As per claim 7, Evans teaches a plurality of pointers to image data, 
wherein the EMR system is capable of displaying the image data when the 
healthcare provider accesses the files using the data manager (Figure 13-14, 
column 4 line 64 to column 5 line 27, column 8 line 29 to column 9 line 37). 

As per claim 9, Evans teaches an electronic medical records system 
capable of being accessed over the Internet (Figure 24, column 2 line 20-45, 
column 16 line 2-20). 

As per claim 10, Evans teaches that the EMR system is capable of 
enabling healthcare providers to remotely enter, access, process, analyze, and 
annotate data from patient records in real-time (column 5 line 1-28). 

As per claim 11, Evans teaches that the healthcare providers are capable 
of accessing patient data remotely (It is noted that patient data is considered to 
be "health indicators") (Figure 24, column 5 line 1-28, column 7 line 5-40, column 
13 line 1-30). 
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As per claim 15, Evans teaches a method capable of being implemented 
by computer (Abstract), comprising: 

(a) communicating between an EMR system (Abstract, column 2 line 21) 
and portable computers (It is noted that communicating with portable computers 
are considered to be "a portability enabling program") (Abstract); 

(b) wherein the EMR system is capable of sharing patient medical records 
between a plurality of external systems (Figure 1 label 106, "EXTERNAL DATA", 
Figure 12, Figure 13 label 219, Figure 17A-B) via a data handler and a 
communication interface (Figure 16 label 272, 274, column 10 line 18-35), and a 
plurality of legacy systems via a data converter (column 12 line 35-53, Figure 
23); 

(c) wherein the EMR system is capable of supporting communication 
among a variety of hardware components (It is noted that a plurality of hardware 
components are considered to be "different... computer platforms") using a 
variety of operating systems (column 13 line 31-56), wherein the hardware 
components comprise: 

(i) a PC (Figure 24 label 412, 416, 418); 

(ii) a pen-based portable computer (It is noted that the pen-based 
portable computer is considered to be "a hand-held device") (Figure 24 
label 420); 

(iii) a network (Figure 24 label 404, 414); 
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(d) wherein the EMR system is capable of populating and updating the 
patient record with text (Figure 14 label 223) and image data (Figure 14 label 
225) from legacy data systems (column 8 line 57-60) and external sources 
(column 8 line 18 to column 9 line 37); 

(e) wherein image data is stored in a plurality of formats (Figure 14 label 

225); 

(f) wherein the EMR system is capable of capturing patient data during a 
patient encounter with a physician (It is noted that encounter data is considered 
to be "patient episode data") (column 6 line 10 line 10-36, Figure 4) and 
controlling access thereto via a password system (It is noted that the password 
system is considered to be "a secure file") (column 15 line 21-32); 

(g) wherein the patient data comprises e-mails from other healthcare 
providers (column 8 line 67 to column 9 line 1). 

Evans further teaches that the patient data repository comprises a 
relational database supporting the Open Database Connectivity (ODBC) model, 
wherein OBDC is an application program interface (API) capable of enabling 
client applications running under Microsoft Windows to access data from a 
variety of data sources, including relational and non-relational DBMS, wherein 
these data sources may reside on a client machine or on a remote server 
(column 14 line 8-25). 

Evans further teaches a patient locator capable of locating patient data in 
a plurality of external sources (column 8 line 18 to column 9 line 37). 
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Examiner submits that the ODBC model and patient locator of Evans are 
considered to be a form of "a master control file" when viewed in light of 
Applicant's specification. 

Notwithstanding the above, page 3 paragraph 3 of Applicant's 
specification reads as follows: 

"One way of providing a common set of medical information 
communications protocols, or common standards, is by an architecture which 
includes the use of a master control file. A master control file (or MCF) is 
middleware software storing information which, when read by a computer 
program referred to as an engine, provides an interface between an application 
program and the WINDOWS operating system. The master control file (or MCF) 
provides an open, interoperable, platform and language independent 
distributed (MCF) architecture . This approach has been enormously successful 
and has been adopted by numerous large firms around the world as the basic 
architecture for their complex Patient Record information systems. This 
infrastructure provides a great deal of power, scalability, and interoperability." 
(emphasis added) 

At the time the invention was made, it would have been obvious to one of 
ordinary skill in the art to include the features of AAPA within the invention as 
disclosed by Evans with the motivation of enabling client applications to access 
data from a plurality of external data sources (Evans; column 14 line 11-14). 

Evans and AAPA do not teach: 

(a) "transmitting the secure file as an e-mail attachment"; 
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(b) "retrieving the patient episode data from the secure file"; 

(c) "storing the patient episode data in the medical records system". 
Hacker teaches a system (Abstract) capable of: 

(a) attaching updated information from the patient visit to an e-mail 
(column 8 line 41-42); 

(b) translating the attached information by software on the server (It is 
noted that translating data is considered to be "retrieving") (column 8 line 43); 

(c) updating the patient medical record on the medical information 
database with the translated data (column 8 line 44-45). 

Evans teaches a password system, as discussed above and incorporated 

herein. 

It is also noted that the official notice taken in the previous Office Action is 
taken to be AAPA because Applicant failed to traverse Examiner's assertion. 
Page 7 of the previous Office Action reads as follows: "It is well known that 
emailing data over a network requires some form of security for the data". 

At the time the invention was made, it would have been obvious to one of 
ordinary skill in the art to include the features of Hacker and AAPA within the 
invention as disclosed by Evans and AAPA with the motivation of providing 
privacy for patient records (Hacker; column 6 line 1-10), and of providing 
convenience to medical providers who have their own electronic medical record 
system and only need access to very little "outside" medical information (Hacker; 
column 8 line 25-34). 
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As per claim 16, Evans teaches a graphical user interface (It is noted that 
the GUI is considered to be "medical software") capable of being deployed on a 
wireless pen-based or laptop computer (Figure 24, column 6 line 9-55, column 13 
line 12-30). 

As per claim 17, Evans teaches that the ODBC/API is capable of enabling 
client applications to access data from a variety of data sources, wherein the 
client is capable of storing, annotating, entering, and accessing patient medical 
records stored in the patient data repository (column 5 line 1-28, column 14 line 
8-25). 

As per claim 18, Evan teaches a data manager/patient locator capable of 
creating a data structure comprising a patient identifier, wherein the data 
structure comprises pointers to data structures having data within a patient 
record captured by a pointer of care system (e.g., X-ray images), wherein there 
exists a plurality of data structures created by the patient locator comprising 
patient data, interface files, clinical data, progress notes (Figure 13), wherein the 
files comprises patient data types (reads on "field names, attributes") (Figure 12 
column 8 line 29-60). 

As per claim 19, Evans teaches database tables comprising a plurality of 
field names, comprising a patient identifier (Figure 13), wherein the EMR system 
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is capable of using the field names to locate, store, and retrieve data (Figure 13, 
column 5 line 1-28, column 8 line 29 to column 9 line 37). 

As per claim 20, Evans teaches a plurality of pointers to a plurality of 
patient data structures, comprising a reference database, wherein the patient 
data structure and patient locator are capable of using the pointers to locate, 
store, and retrieve data (Figure 13, column 5 line 1-28, column 8 line 29 to 
column 9 line 37). 

As per claim 21 , Evans teaches a plurality of pointers to image data, 
wherein the EMR system is capable of displaying the image data when the 
healthcare provider accesses the files using the data manager (Figure 13-14, 
column 4 line 64 to column 5 line 27, column 8 line 29 to column 9 line 37). 

As per claim 23, Evans teaches an electronic medical records system 
capable of being accessed over the Internet (Figure 24, column 2 line 20-45, 
column 16 line 2-20). 

As per claim 24, Evans teaches that the EMR system is capable of 
enabling healthcare providers to remotely enter, access, process, analyze, and 
annotate data from patient records in real-time (column 5 line 1-28). 



# 
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As per claim 25, Evans teaches that the healthcare providers are capable 
of accessing patient data remotely (It is noted that patient data is considered to 
be "health indicators") (Figure 24, column 5 line 1-28, column 7 line 5-40, column 
13 line 1-30). 

As per claims 29, 30, 31, 32, 33, 34, 35, 37, 38, 39, Evans, Hacker, and 
AAPA teach the method of claims 15, 16, 17, 18, 19, 20, 21, 23, 24, 25, 
respectively, as discussed above and incorporated herein. See MPEP 
2106.01(1). 

As per claim 43, Evans teaches a system (It is noted that a system is 
considered to be "an apparatus") (Abstract), comprising: 

(a) an EMR system (It is noted that the EMR system is considered to be "a 
computer system") (Abstract, column 2 line 21) capable of communicating with 
portable computers (It is noted that communicating with portable computers are 
considered to be "executing portability enabling software") (Abstract); 

(b) wherein the EMR system is capable of sharing patient medical records 
between a plurality of external systems (Figure 1 label 106, "EXTERNAL DATA", 
Figure 12, Figure 13 label 219, Figure 17A-B) via a data handler and a 
communication interface (Figure 16 label 272, 274, column 10 line 18-35), and a 
plurality of legacy systems via a data converter (column 12 line 35-53, Figure 
23); 
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(c) wherein the EMR system is capable of supporting communication 
among a variety of hardware components (It is noted that a plurality of hardware 
components are considered to be "different... computer platforms") using a 
variety of operating systems (column 13 line 31-56), wherein the hardware 
components comprise: 

(i) a PC (Figure 24 label 412, 416, 418); 

(ii) a pen-based portable computer (It is noted that the pen-based 
portable computer is considered to be "a hand-held device") (Figure 24 
label 420); 

(d) wherein the EMR system is capable of populating and updating the 
patient record with text (Figure 14 label 223) and image data (Figure 14 label 
225) from legacy data systems (column 8 line 57-60) and external sources 
(column 8 line 18 to column 9 line 37); 

(e) wherein image data is stored in a plurality of formats (Figure 14 label 

225); 

(f) wherein the EMR system is capable of capturing patient data during a 
patient encounter with a physician (It is noted that encounter data is considered 
to be "patient episode data") (column 6 line 10 line 10-36, Figure 4) and 
controlling access thereto via a password system (It is noted that the password 
system is considered to be "a secure file") (column 15 line 21-32); 

(g) wherein the patient data comprises e-mails from other healthcare 
providers (column 8 line 67 to column 9 line 1). 
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Evans further teaches that the patient data repository comprises a 
relational database supporting the Open Database Connectivity (ODBC) model, 
wherein OBDC is an application program interface (API) capable of enabling 
client applications running under Microsoft Windows to access data from a 
variety of data sources, including relational and non-relational DBMS, wherein 
these data sources may reside on a client machine or on a remote server 
(column 14 line 8-25). 

Evans further teaches a patient locator capable of locating patient data in 
a plurality of external sources (column 8 line 18 to column 9 line 37). 

Examiner submits that the ODBC model and patient locator of Evans are 
considered to be a form of "a master control file" when viewed in light of 
Applicant's specification. 

Notwithstanding the above, page 3 paragraph 3 of Applicant's 
specification reads as follows: 

"One way of providing a common set of medical information 
communications protocols, or common standards, is by an architecture which 
includes the use of a master control file. A master control file (or MCF) is 
middleware software storing information which, when read by a computer 
program referred to as an engine, provides an interface between an application 
program and the WINDOWS operating system. The master control file (or MCF) 
provides an open, interoperable, platform and language independent 
distributed (MCF) architecture . This approach has been enormously successful 
and has been adopted by numerous large firms around the world as the basic 
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architecture for their complex Patient Record information systems. This 
infrastructure provides a great deal of power, scalability, and interoperability." 
(emphasis added) 

At the time the invention was made, it would have been obvious to one of 
ordinary skill in the art to include the features of AAPA within the invention as 
disclosed by Evans with the motivation of enabling client applications to access 
data from a plurality of external data sources (Evans; column 14 line 11-14). 

Evans and AAPA do not teach: 

(a) "transmitting the secure file as an e-mail attachment"; 

(b) retrieving the patient episode data from the secure file"; 

(c) "storing the patient episode data in the medical records system". 
Hacker teaches a system (Abstract) capable of: 

(a) attaching updated information from the patient visit to an e-mail 
(column 8 line 41-42); 

(b) translating the attached information by software on the server (It is 
noted that translating data is considered to be "retrieving") (column 8 line 43); 

(c) updating the patient medical record on the medical information 
database with the translated data (column 8 line 44-45). 

Evans teaches a password system, as discussed above and incorporated 

herein. 

It is also noted that the official notice taken in the previous Office Action is 
taken to be AAPA because Applicant failed to traverse Examiner's assertion. 
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Page 7 of the previous Office Action reads as follows: "It is well known that 
emailing data over a network requires some form of security for the data". 

At the time the invention was made, it would have been obvious to one of 
ordinary skill in the art to include the features of Hacker and AAPA within the 
invention as disclosed by Evans and AAPA with the motivation of providing 
privacy for patient records (Hacker; column 6 line 1-10), and of providing 
convenience to medical providers who have their own electronic medical record 
system and only need access to very little "outside" medical information (Hacker; 
column 8 line 25-34). 

As per claim 44, Evans teaches a network (Figure 24 label 404, 414). 

Claim(s) 12, 26, 40 is/are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Evans in view of Hacker and AAPA as applied to parent 
claims 9, 15 above, respectively, and further in view of Swanson (61 12183). 

As per claim 12, Evans teaches that the EMR system is capable of 
capturing data in a point of care system (column 16 line 2-20) and securing data 
using a tiered-password system (column 15 line 8-32). 

Evans does not teach "compresses, encrypts, and encapsulates patient 
episode data into the secure file". 

It is noted that the official notice taken in the previous Office Action is 
taken to be AAPA because Applicant failed to traverse Examiner's assertion. 
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Page 10 of the previous Office Action reads as follows: "it is well known in the art 
to compress data, encrypt data, and encapsulate patient data". 

Swanson also teaches encryption, compression, and encapsulation 
(column 2 line 26-31). 

At the time the invention was made, it would have been obvious to one of 
ordinary skill in the art to include the features of Swanson and AAPA within the 
invention as disclosed by Evans, Hacker, and AAPA with the motivation of 
providing superior protection of patient data (Evans; column 15 line 29-32). 

As per claim 26, Evans teaches that the EMR system is capable of 
capturing data in a point of care system (column 16 line 2-20) and securing data 
using a tiered-password system (column 15 line 8-32). 

Evans does not teach "compressing, encrypting, and encapsulating 
patient episode data into the secure file". 

It is noted that the official notice taken in the previous Office Action is 
taken to be AAPA because Applicant failed to traverse Examiner's assertion. 
Page 10 of the previous Office Action reads as follows: "it is well known in the art 
to compress data, encrypt data, and encapsulate patient data". 

Swanson also teaches encryption, compression, and encapsulation 
(column 2 line 26-31). 

At the time the invention was made, it would have been obvious to one of 
ordinary skill in the art to include the features of Swanson and AAPA within the 
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invention as disclosed by Evans, Hacker, and AAPA with the motivation of 
providing superior protection of patient data (Evans; column 15 line 29-32). 

As per claim 40, Evans, Hacker, AAPA, and Swanson teach the method of 
claim 26, as discussed above and incorporated herein. See MPEP 2106.01(1). 

Claim(s) 13-14, 27-28, 41-42 is/are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Evans in view of Hacker, AAPA, and Swanson as 
applied to parent claims 12, 12, 26, 26, 40, 40 above, respectively, and further in 
view of Haudenschild (6665647). 

As per claims 13-14, Evans, Hacker, AAPA, and Swanson do not teach: 

(a) "transmits the secure file to a repository mail sever, which de- 
encapsulates and uncompresses the secure file and stores the de-encapsulated, 
uncompressed secure file into a patient medical record"; 

(b) "a messages is transmitted to an assigned physician notifying the 
assigned physician of the receipt of the patient episode data". 

Haudenschild teaches a system (Abstract) capable of encrypting sensitive 
data at one end of transmission and decrypting the encrypted data at the other 
end of transmission, and notifying all parties via messages (column 6 line 48-65). 

At the time the invention was made, it would have been obvious to one of 
ordinary skill in the art to include the features of Haudenschild within the 
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invention as disclosed by Evans, Hacker, AAPA, and Swanson with the 
motivation of protecting sensitive data (Haudenschild; column 6 line 48-65). 

As per claims 27-28, Evans, Hacker, AAPA, and Swanson do not teach: 

(a) "transmitting the secure file to a repository mail sever"; 

(b) "de-encapsulating and uncompressing the secure file"; 

(c) "storing the de-encapsulated, uncompressed secure file into a patient 
medical record"; 

(d) "transmitting transmitted to an assigned physician notifying the 
assigned physician of the receipt of the patient episode data". 

Haudenschild teaches a system (Abstract) capable of encrypting sensitive 
data at one end of transmission and decrypting the encrypted data at the other 
end of transmission, and notifying all parties via messages (column 6 line 48-65). 

At the time the invention was made, it would have been obvious to one of 
ordinary skill in the art to include the features of Haudenschild within the 
invention as disclosed by Evans, Hacker, AAPA, and Swanson with the 
motivation of protecting sensitive data (Haudenschild; column 6 line 48-65). 

As per claims 41, 42, Evans, Hacker, AAPA, Swanson, and 
Haundenschild teach the method of claims 27, 28, respectively, as discussed 
above and incorporated herein. See MPEP 2106.01(1). 
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Response to Arguments 

Applicant's arguments filed 06/04/2007 have been fully considered but 
they are not persuasive. 

As per claim 1, on page 11-14 of the Remarks Applicant argues that 
AAPA does not admit "a master control file" as claimed. 

Page 3 paragraph 3 of Applicant's specification reads as follows: 
"One way of providing a common set of medical information 
communications protocols, or common standards, is by an architecture which 
includes the use of a master control file. A master control file (or MCF) is 
middleware software storing information which, when read by a computer 
program referred to as an engine, provides an interface between an application 
program and the WINDOWS operating system. The master control file (or MCF) 
provides an open, interoperable, platform and language independent 
distributed (MCF) architecture This approach has been enormously successful 
and has been adopted by numerous large firms around the world as the basic 
architecture for their complex Patient Record information systems. This 
infrastructure provides a great deal of power, scalability, and interoperability." 
(emphasis added) 

Although Applicant argues that this portion of the specification and Figure 
3 of the drawings refer to an MCF between already compatible systems, the 
emphasized sections above clearly states that the MCF provides an 
"interoperable" and "platform and language independent" architecture. 
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Assuming arguendo that Applicant is correct that Figure 3 does not 
illustrate an MCF between different systems, at least the cited sections above 
illustrate that an MCF capable of providing interoperability between systems of 
different platforms and languages is old and well established in the art. 

On page 14 Applicant further argues that Evans does not teach "a master 
control file". 

Examiner submits that the ODBC model and patient locator of Evans are 
considered to be a form of "a master control file" when viewed in light of 
Applicant's specification, as discussed above and incorporated herein. 

Examiner further notes that page 5 of the previous Office Action reads as 
follows: "Evans does not explicitly disclose "a master control file". It appears, 
however, that ODBC model and patient locator are a form of a master control file 
when viewed in light of Applicant's specification". 

Notwithstanding the above, AAPA admits an MCF, as discussed above 
and incorporated herein. 

The remainder of Applicant's arguments on page 15-17 merely repeats 
the arguments addressed above, and incorporated herein. 

Conclusion 

The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure: 
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De Moor (Towards a meta-syntax for medical edi) teaches a method of 
translating messages to provide interoperability between a plurality of systems. 

Any inquiry concerning this communication or earlier communications from 
Examiner should be directed to Tran N. Nguyen (Ken) whose telephone number 
is (571 ) 270-1310. The examiner can normally be reached on Monday - Friday, 
9:00 am - 5:00 pm, Eastern Time. 

If attempts to reach the examiner by telephone are unsuccessful, 
Examiner's Supervisor, Joseph Thomas can be reached on (571) 272-6776. 

Information regarding the status of an application may be obtained from 
the Patent Application Information Retrieval (PAIR) system. Status information 
for published applications may be obtained from either Private PAIR or Public 
PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see http://pair- 
direct.uspto.gov. Should you have questions on access to the Private PAIR 



system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll- 
free). If you would like assistance from a USPTO Customer Service 
Representative or access to the automated information system, call 800-786- 
9199 (IN USA OR CANADA) or 571-272-1000. 
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